Virtual entity on a network

ABSTRACT

An electronic communication device carries character-specific data, and an avatar common to multiple characters, for representing a character on the device, and a character sharing unit for using the interconnectivity of the device to allow sharing of the character over a network. The character is one that can be developed through use over time, and the sharing of the characters creates a user community.

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a virtual entity on a network, moreparticularly but not exclusively to issues of presence or exchange of ananimated character over a network and, more particularly, but notexclusively to presence or exchange of the character over a cellulartelephony network.

The animated character may be a representative of the user, an avatar,or it may be a character relating to a computer game or any other kindof animated character, including an animated self-developing pet. Theself-developing electronic pet is a game that involves a characterrequiring consistent attention from its owner in order to thrive. If itreceives the attention it grows and develops, if it does not then itdeteriorates. The idea is that the pet is constantly present andrequires constant attention from its owner.

The self-developing pet is generally based on a physical doll. Thephysical doll has a processor and memory, and has a physical existence.It can be given to people and returned. The self-developing pet requiresattention as described above. It is in principle also possible to have avirtual self-developing pet which is an animated character supported bya computer. The virtual self-developing pet detracts from the basic ideaof the original physical self-developing pet in that it is notconstantly present with the user and therefore cannot demand constantattention. The virtual self-developing pet is limited by the fact that acomputer is not constantly switched on, or even if switched on, is notconstantly present with the user. Even if the computer is a mobilecomputer, it is very awkward for a user to interact with the computerwhilst he/she is walking for example. Furthermore part of the experienceof the self-developing pet is to share it with friends. The physicalself-developing pet can be physically shared with friends, however thevirtual self-developing pet can only be shared if issues of presence aredealt with. Thus it must be ensured that the virtual self-developing petis not present at two locations at once, or that the virtualself-developing pet is not lost from all locations. The virtualself-developing pet is also required to develop over time, bothphysically and emotionally, just as a real pet grows and learns.

The present disclosure deals with issues of a virtual self-developingpet, including continuous availability of the virtual self-developingpet with its owner, the ability to share the virtual self-developing petwith others and issues involved in building a virtual community for theself-developing pet.

SUMMARY OF THE INVENTION

According to one aspect of the present invention there is provided anelectronic device carrying computing functionality, displayfunctionality, and interconnectivity functionality for transmitting dataover a network, the device comprising: dynamic data, and static data,said dynamic and static data being combinable to represent a characteron said device, and a character sharing unit for using saidinterconnectivity functionality to allow said character to be sharedwith other devices over said network.

According to a second aspect of the present invention there is provideda system comprising a plurality of mobile communication devices, eachdevice having computing, display and communication functionality, andcomprising: an engine for operating characters, the characters havingpersonal behavior and an avatar, and an exchange unit for allowing saidcharacters to be exchanged with other mobile devices so as to operatewith the same personal behavior and appearance thereon, thereby toprovide a community environment for operating said characters.

According to a third aspect of the present invention there is provided amethod of exchanging characters over a mobile telephony network betweena plurality of mobile devices, comprising: providing at each of saidplurality of mobile devices a behavior engine for providingcharacter-specific behavior according to character-specific behaviorparameters; providing at each of said plurality of mobile devices staticdata for display of respective characters, and exchanging a givencharacter between mobile devices by sending respectivecharacter-specific behavior parameters and identifying relevant staticdata.

According to a fourth aspect of the present invention there is provideda system for interaction between limited resource devices, each devicecomprising a local copy of a common user client, the devices beingconfigured to exchange at least one text message to communicateparameter data for said commonly held user client.

According to a fifth aspect of the present invention there is provided asystem for interaction between limited resource devices, wherein thelimited resource devices are configured with a client for exchange oftext-encoded binary data, for direct contact between said limitedresource devices.

According to a sixth aspect of the present invention there is provided amethod of electronic competition comprising:

developing attributes through a first electronic character,

setting a competitive task for said electronic character to perform withat least one other electronic character having corresponding attributeswithin a first virtual environment; and

within said first virtual environment selecting a winner of saidcompetitive task from said first and said at least one other charactersvia assessment of a development level of said attributes.

According to a seventh aspect of the present invention there is provideda method of communicating binary information between client applicationson mobile devices comprising:

formulating said binary information into at least one text message at aclient application on a first mobile device, said text message beingformulated for reading by a corresponding client application on arecipient mobile device;

adding to said text message a human readable header to appear onrecipient mobile devices not equipped with a corresponding clientapplication; and sending said text message to a recipient.

Unless otherwise defined, all technical and scientific terms used hereinhave the same meaning as commonly understood by one of ordinary skill inthe art to which this invention belongs. The materials, methods, andexamples provided herein are illustrative only and not intended to belimiting.

Implementation of the method and system of the present inventioninvolves performing or completing certain selected tasks or stepsmanually, automatically, or a combination thereof. Moreover, accordingto actual instrumentation and equipment of preferred embodiments of themethod and system of the present invention, several selected steps couldbe implemented by hardware or by software on any operating system of anyfirmware or a combination thereof. For example, as hardware, selectedsteps of the invention could be implemented as a chip or a circuit. Assoftware, selected steps of the invention could be implemented as aplurality of software instructions being executed by a computer usingany suitable operating system. In any case, selected steps of the methodand system of the invention could be described as being performed by adata processor, such as a computing platform for executing a pluralityof instructions.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, withreference to the accompanying drawings. With specific reference now tothe drawings in detail, it is stressed that the particulars shown are byway of example and for purposes of illustrative discussion of thepreferred embodiments of the present invention only, and are presentedin order to provide what is believed to be the most useful and readilyunderstood description of the principles and conceptual aspects of theinvention. In this regard, no attempt is made to show structural detailsof the invention in more detail than is necessary for a fundamentalunderstanding of the invention, the description taken with the drawingsmaking apparent to those skilled in the art how the several forms of theinvention may be embodied in practice.

In the drawings:

FIG. 1 is a simplified diagram showing a self-developing pet beingexchanged between two mobile devices according to a first embodiment ofthe present invention;

FIG. 2 is a simplified diagram showing the arrangement of data for theself-developing pet of FIG. 1 into static and dynamic data;

FIG. 3 is a simplified diagram illustrating data exchange via a textmessage according to a preferred embodiment of the present invention;

FIG. 4 is another simplified diagram showing blocks of an engine forsupporting a self-developing pet application, according to a preferredembodiment of the present invention;

FIG. 5 is a simplified diagram illustrating a process for generating atext encoded binary text message, according to a preferred embodiment ofthe present invention;

FIG. 6 is a simplified diagram illustrating the structure of the SMSmessage of FIG. 5;

FIG. 7 illustrates a simplified procedure for receiving aself-developing pet according to a preferred embodiment of the presentinvention;

FIG. 8 is a simplified diagram illustrating the sending of a decorationaccording to a preferred embodiment of the present invention;

FIG. 9 is a simplified flow diagram illustrating the sending of a snack,according to a preferred embodiment of the present invention;

FIG. 10 is a block diagram of the sending procedure for aself-developing pet, according to a preferred embodiment of the presentinvention and particularly showing the points at which loss ofsynchronization can lead to loss of the pet;

FIG. 11 is a flow diagram of a scheme for automatic retrieval of the petin the event of a timeout, according to a preferred embodiment of thepresent invention;

FIG. 12 is a flow diagram of synchronization using a time stampaccording to a preferred embodiment of the present invention;

FIG. 13 is a block diagram of a trait and emotion engine according to apreferred embodiment of the present invention;

FIG. 14 is a diagram showing how a change function can be used to changefrom a first set of traits to a second set of traits, according to apreferred embodiment of the present invention;

FIG. 15 is a flow diagram illustrating the principle that two charactersmay be changed in different ways by the same external action, accordingto a preferred embodiment of the present invention;

FIGS. 16 and 17 show screen shots illustrating the principle of FIG. 15;

FIGS. 18A-C are simplified diagrams showing three different ranges oftraits respectively. FIG. 18B shows how a particular range may define anoverall emotion;

FIGS. 19A-C are simplified diagrams showing how a change functionchanges traits directly and indirectly changes the emotion through thetraits, according to the three ranges of FIGS. 18A-C;

FIG. 20 is a flow chart that illustrates the principle that an externalaction causes a pet to act to accept or reject according to a presentstate, also causes changes of state according to the choice of action,and the new state leads to a new set of actions;

FIG. 21 illustrates a series of interaction tables for pet, traits,emotions and actions, according to a preferred embodiment of the presentinvention;

FIGS. 22-24 are a series of screen shots illustrating a race applicationinvolving two self-developing pets, according to a preferred embodimentof the present invention; and

FIG. 25 is a simplified diagram illustrating the operational flow duringthe race of the application of FIGS. 22-24.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present embodiments comprise an apparatus and a method forsupporting a self-developing pet on a mobile device and for creating anetworked community of self-developing pet owners. The self-developingpet community is based on a single model that includes basic pet traitsand behaviors including emotion, and a set of avatars. The model and theset of avatars are present on all the mobile devices in the community.The individual pet is then formed from a selected one of the avatars andan evolving set of parameters for the model. The individual pet has anowner device and may be transferred to and from other devices simply byspecifying the current set of parameters and the selected avatar. Such atransfer is preferably carried out using binary data within a textmessage.

When transferring the pet, preferred embodiments ensure that the pet hasa single presence at all times, meaning that its parameter set can onlybe independently updated on one device at a given time. Furthermore theembodiment ensures that the pet is not lost if a particular device failsto receive it or fails to send it back to the owner.

At a deeper level the embodiments encompass communication betweenlimited resource devices using binary encoded text, the communicationbetween limited resource devices using text messaging, the communicationbetween applications on different limited resource devices using textmessaging and the communication between such applications using binaryencoded text.

In addition the embodiments teach the creation of a community for theuse of such animations, including a competitive environment for users totest their own pets against others.

The principles and operation of an apparatus and method according to thepresent invention may be better understood with reference to thedrawings and accompanying description.

Before explaining at least one embodiment of the invention in detail, itis to be understood that the invention is not limited in its applicationto the details of construction and the arrangement of the components setforth in the following description or illustrated in the drawings. Theinvention is capable of other embodiments or of being practiced orcarried out in various ways. Also, it is to be understood that thephraseology and terminology employed herein is for the purpose ofdescription and should not be regarded as limiting.

Reference is now made to FIG. 1, which is a simplified diagramillustrating two electronic devices, such as mobile telephones or otherwireless or cellular communication devices, being used in accordancewith a first preferred embodiment of the present invention. The devicescarry computing functionality, display functionality, andinterconnectivity functionality for transmitting data over a network. Asillustrated, a self-developing pet is present on a first telephone 10,and its presence is represented by screen avatar 12. The identity of thepet, including a pointer to the avatar, as well as the parameters forthe behavior model that individualize the pet, are encoded in binaryformat into a text message, typically an SMS message, so that the petmay be sent over the cellular network to a friend's telephone 14. Avatar12 then appears on the friend's telephone to indicate the presence thereof the pet.

It is noted in passing that SMS is suitable for sending over thetelephony network. However the use of other networks may alsoadvantageously be used by the present embodiments. Two telephoneslocated near each other may transfer data using an IR link between theirrespective IR ports. The binary SMS file is small and is thereforesuitable for forming the basis of an IR communication. Likewise a localHotpoint or Bluetooth™ connection could be used. The use of suchconnections may typically require minor additions to the user client.

Reference is now made to FIG. 2, which illustrates how data of the petis organized. Data is organized as static data (type A) that is commonto all the clients in the community, such as 3D model data 20, texture22, animations 24 and sounds 26, and data that varies between pets orover time, (type B).

That is to say, the user clients contain the type A or staticinformation, which is all of the information needed to support acommunity of pets. This includes a model of pet behavior, animations,textures and the like. Some of this static information such as the modelapplies to all of the different pets. Other information applies to somepets and not others. Thus a particular avatar may be shared by all dogsof the same kind. Data of type B is dynamic data that varies betweenpets. It may include the name, age and kind of a particular pet, as wellas the current state of its traits. It is pointed out that the traitvalues of the pet, as will be discussed in greater detail below, are infact parameters for the pet behavior model. The dynamic behaviorincludes information which changes over the lifetime of a pet, such asthe current state of a particular trait, or its age, and informationwhich remains the same for a given pet over its lifetime such as itsname. The dynamic information also includes data that is common to allpets of the same kind, thus a pointer to the correct avatar.

The dynamic data, including character specific data, together with anavatar which is common to multiple characters, say all dogs of a givenbreed, provides a representation of a given pet. The character specificdata includes behavior parameters, as will be discussed in more detailhereinbelow, and the behavior parameters are allowed to evolve accordingto certain rules contained within the model. The model may further useparameters to be individualized for different breeds. It is thisevolution of the behavior parameters that makes the pet into aself-developing pet.

Referring now to FIG. 3, the static data is present on all machines sothat a character sharing unit may be constructed to share an individualpet over the network simply by sending the dynamic data (type B), thusname, age, and parameters or traits. The character sharing unitpreferably uses text messaging, for example SMS, to send the type Bdata.

The avatar is preferably present on all the user clients and thusconstitutes part of the static data, even though not all pets use thesame avatar. Reference is now made to FIG. 4 which is a block diagramillustrating internal operation of a mobile telephone 40 to support theself-developing pet. Sharing unit 42 is as discussed above and ingreater detail below. The static data 44 includes the models andavatars, and the models include the behavior model, as explained above.Dynamic data 46 includes the pet specific information.

Presence control unit 48 controls the character sharing unit to ensurethat the character has a unified presence on the network. The presencecontrol preferably ensures that the same pet is only present on onedevice on the network at a given time. By the term present is meantpartly that the avatar for the same pet only appears on one machine,although certain exceptions may be allowed to this rule. Moreimportantly the presence control ensures that the pet specific data 46can only be updated on one machine at a given time.

The pet may be sent to another device to be shared in some way withanother user. Ways in which the pet can be shared are discussed ingreater detail below. The presence control unit sets a time that the petis expected back. Until that time is reached the pet does not appear onthe originating machine unless it is actually sent back from the otherdevice. If it is sent back from the other device then any modificationsmade to the pet on the other device are accepted as the parameters forthe pet. If the pet does not return by the end of the time period thenthe pet simply reappears at the originating device and its originalparameters are reinstated. If the pet is returned from the other deviceafter the delay expires then any modified parameters from the otherdevice are ignored. The presence feature is discussed in greater detailbelow.

The character sharing unit 42 preferably places a signature on a textmessage carrying the character specific data so that the message can berecognized as belonging to the pet community and thus can be routed tothe appropriate client. If the client is not installed on the receivingphone then the message gets sent directly to the SMS client where it isdisplayed as a text message. Of course the message contains binary dataand is therefore not readable. In a preferred embodiment the textmessage therefore includes a human readable message. Such a message mayfor example inform the user how she can join the self-developing petcommunity. The character specific data is preferably binary data and thecharacter sharing unit is configured to place such binary data in thetext message.

The character sharing unit is likewise configured to scan incoming textmessages for signatures indicative of character data content. Incomingmessages could either be a local pet returning or a visitor petarriving.

The scanning is preferably carried out prior to a respective textmessage being sent to client applications, so that the text message isnot sent to the SMS client before being sent to the pet client.

The character specific information typically comprises emotion parameterdata which operates emotion engine 50. The emotion engine with specificparameter data provides emotion-based behavior which differs between petcharacters and differs over the evolution of a given pet character.

As explained, the emotion engine is configured to evolve the emotionparameter data slowly over time. The evolving behavior providesdevelopment of emotion-based behavior for the pet and makes the pet aself-developing pet.

A feature of the preferred embodiments is that there is no need for aserver-side application for general running since clients are present onthe user devices. Neither is there any need for modification of thenetwork. The only need for a server, if at all is for the initialdownload of the clients and subsequent updating. An embodiment may havea client initially provided in system ROM at manufacture. Thus a serverwould not even be needed for initial download.

In the above it was explained that binary information is sent via textmessage. The choice of text message and binary encoding thereof is nowdiscussed in greater detail.

The issue of sending binary information between telephone users hasthree possible solutions as follows:

a. Peer to peer (P2P) communication: current cellular networks supportP2P communication between phones and the service-provider (operator).This allows transfer of binary content to/from dedicated servers outof/into the users' mobile phones.

b. SMS: A standard protocol that allows users to transfer non-vocal databetween themselves and is supported on all mobile phones and allnetworks. SMS does not in general need server support at the applicationlevel.

c. Infrared/Bluetooth link: A method for transferring binary informationbetween phones which are close to each other, or physically linked.

In the current art these solutions suffer from the followingdisadvantages:

a: P2P communication: Does not operate directly between users, butrather between users and a server. If it is desired to send binary databetween users, it is necessary to establish a server-side solution.

b: SMS: Current SMS applications support only textual content.Furthermore, the SMS protocol sends SMS between telephones, and notbetween applications. SMS allows sending of only very small amounts ofdata.

c: Infrared/Bluetooth link: Requires the users to be physically close toone another.

As explained above, the preferred solution is to send a virtual pet overthe cellular network using binary SMS, and at the same time maintaininga full user client on each telephone. The only data that needs to besent to result in full transfer of the pet is parameter information thatis specific to the individual pet. The parameter information fits intothe limited size of the SMS.

Representation of a Pet

A single virtual pet is represented by a large amount of data. Much ofthis data is dedicated to the physical representation of the animal:3d-models, textures, animations, sounds and so on.

As explained the system acknowledges two types of information, asdiscussed above with respect to FIG. 2:

Static data (shared among all pets or pets of the same kind). The staticdata is part of the user client referred to above and resides on each ofthe phones. The user client may additionally reside on a central server,or certain parts of the user client may reside on the central server,for example certain rarely used parts of the user client. Thus there maybe a regular range of pets provided to everyone, and certain specialpets that users can download especially. Thus in general every usereither already has the user client, or has direct access to the serverin order to download it.

New data may be added to the user client after the application isreleased. For example these may be new sounds, animations and so on. Thenew data is likewise accessible to all telephones, who are able todownload the data as updates from the central server.

The physical representation that is included in the user client isstatic, that is non-changing, data of the pet, includingthree-dimensional models, textures, animations, and sounds. Such data isthe same for all pets of the same kind and is therefore held in commonwithin the user client.

Non-static data: The non-static data is the information needed torepresent a specific pet. This data is created and stored in the user'stelephone. It changes over time, according to the user's actions, as itis supposed to represent a living, changing organism.

The non-static data is the only data needed to reconstruct a specificpet on another phone, since, as explained, the other phone includes auser client. Each specific pet need only store references to the staticdata it uses, not the data itself. Such is possible since the staticdata is already on the user's phone, or can be downloaded from apredefined server. Many different pets can share the same static data.

The following is an example of three pets who take model and texturedata from the user client and have their own specific parameters forname and age:

-   Pet 1: Name “Johnny”, Age: 12 days, Breed: “Cocker-spaniel”,    Texture: “Brown”.-   Pet 2: Name “Mookey”, Age: 93 days, Breed: “Jindo”, Texture:    “Brown”.-   Pet 3: Name “Poko”, Age: 2 days, Breed: “Jindo”, Texture: “Yellow”.

The data stored for each specific pet is as follows:

Name, Age, Traits (strength, intelligence etc), Breed (which correspondsto a 3d-model).

The amount of data needed to be sent, in order to reconstruct a certainpet on the other side is, therefore, very small. Only the non-staticdata is sent. It is noted that the traits information may be invisible.That is to say it affects the behavior of the pet but it need notnecessarily be brought directly to the attention of the user. Parameterdata for the behaviour or emotion model may be provided. Such data maybe part of the traits information or provided independently, and isdiscussed in greater detail below.

In the following the general flow of sending a pet via SMS is discussedwith reference to FIG. 5.

First of all the pet instance, that is all the specific data includingparameters, is gathered and compressed into an SMS message, stage 501.The data is then streamed into a binary stream in stage 503. The SMSformat has two limitations which make the task difficult:

A. The SMS format is textual and not binary, as it is intended forwritten text messages.

The representation of a pet is binary information.

B. SMS messages are limited to a small number of characters, currently80 characters. Since it is desired to send a complete representation ofa pet in one SMS message, sufficient data should thus fit within the 80character length.

A preferred embodiment overcomes limitation A by converting theinformation from binary to textual in stage 505. A preferred conversionuses the 7-bit method known to the skilled person. In the 7-bit method,each 7 bits of the binary information are converted to 1 textualcharacter. The 7-bit method has the unfortunate side-effect of inflatingthe overall size of the data by 15% due to the loss of 1 bit for everybyte. As to limitation B: as explained hereinabove, actually very littlebinary information is needed to represent a specific pet since thesystem assumes the existence of the static shared data, as explained.

Constructing the SMS Message

The above is not sufficient for creating an SMS message that can be sentto other mobile telephones. The SMS message itself may preferablyinclude extra information, beside the pet instance information:

Some header information is needed to identify the message as a specialSMS. SMS messages were originally designed for textual messages and aregenerally automatically sent to a user's SMS client which displays themessage automatically on the user's screen. In this case, displaying thecontent of the message is useless. The message rather needs to berecognized prior to being picked up by the SMS client and redirected tothe self-developing pet application for parsing. A suitable headerallows the receiving phone to identify the SMS and direct it to therelevant application, before it is displayed on the screen.

In some cases the SMS message containing the pet may be sent to atelephone which does not have the self-developing pet applicationinstalled. In this case, the content of the message will automaticallybe displayed, because there is nothing to recognize the headers andnowhere to divert the message to anyway. The SMS thus appears on thescreen as a random collection of characters. It is therefore necessaryto add some coherent text at the beginning of the message for thebaffled receiver to understand what has happened. Thus the message mayinclude a plain text tag such as “Phone Pet—not supported on yourphone”, or “U have been sent a pet. Dial *111 to unlock”.

When the same message arrives at a telephone where the application isinstalled, the message itself will not be shown at all—but directedimmediately to the self-developing pet application, as discussed. Themechanism is explained in greater detail later on.

Reference is now made to FIG. 6, which superimposes onto FIG. 5 theresultant SMS message.

The SMS message contains three parts as follows:

a. Header 601. The header preferably comprises two characters, andidentifies the message as a Pet SMS.

b. Not-supported message 603. A message, as described above appears onthose phones which do not support our application.

c. Pet information 605. This part of the message includes the actualbinary information needed to reconstruct the pet. This is the non-staticdata referred to above. Reference is now made to FIG. 7, which is asimplified diagram illustrating sending of the SMS and its reception atanother mobile telephone, the receiving telephone or recipient.

When the SMS arrives at a recipient who has self-developing pet support,stage 701, the message is first identified as a special message in stage703. There is thus provided a sniffer application which inspects everyincoming message. If the first two characters correspond to thepredefined header signature, the message is directed to theself-developing pet application rather than being displayed on thescreen.

Once the content of the message is delivered to the self-developing petapplication, the application is able to begin a process of parsing themessage. Parsing only requires part 605 of the message which carries thetext encoded binary data. The header 601 and non-supported message 603have by now served their purpose in getting the message to theapplication and thus cease to be relevant.

The pet information is now decoded in a process which is the reverse ofthe encoding process.

Since SMS messages may become corrupted over the network, a validationtest is necessary at this point, stage 705. The parameters of thereceived pet are firstly tested against a set of reasonable conditions,for example a requirement that the age parameter cannot be negative. Ifeven one of the parameters does not pass the test, the entire SMS ispreferably discarded. Otherwise the binary data is used to reconstructthe pet 707 which is then displayed on the recipient's screen 709.

In the event that the message is received by a recipient who is notconfigured with the self-developing pet application, the message itselfis directly displayed on the screen. Immediately following the header isthe message 603 indicating that the feature is not supported, so thatthe recipient is able to understand what is happening.

Within the scope of the self-developing pet application, there may beother interactions between self-developing pet clients for which SMSmessaging, aside from the sending of pets, can be used which enhance thecommunity experience of the self-developing pet. FIGS. 8 and 9 are flowcharts illustrating two examples of such interactions. FIG. 8illustrates the sending of a decoration or accessory to a particularpet, and FIG. 9 illustrates the sending of a cake.

Referring now to FIG. 8, a decoration or accessory is an object the petcan wear (medal, sun-glasses, hat, etc). Representing a decoration issimilar to the way a pet is represented: there is a global repository ofstatic information (3d models and textures of the decorations). Theamount of data needed to reconstruct the decoration on the other side istherefore very small: reference to the name of the 3d-model to use, thecolor and so on. In FIG. 8 the decoration is shown on the originator'spet in stage 801. The decoration is transferred using a text-encodedbinary SMS in stage 803 and the accessory is shown on the pet of therecipient in stage 805.

Referring now to FIG. 9, and the same principle is illustrated for asnack. A snack is a present the user (owner) can give to her own oranother pet (i.e. cake, dried-meat etc). Giving the pet a snack improvesits emotional state in some way. Once again, there is a finite databaseof available snacks, and the message transfer, stages 901, 903, 905require only to send the ID of the specific snack being provided.

Reference is now made to FIG. 10, which is a simplified flow chartillustrating time delays involved in transferring a pet from onetelephone to another. That is to say SMS delivery is asynchronous anddoes not usually involve confirmations. The asynchronous nature of thedelivery can give rise to pets being present at two locations at thesame time or being deleted from all locations.

More particularly, when the message is sent the user does not know forsure when, or even if at all, it will arrive. The message may takeseveral seconds, or minutes. In any case, the recipient's phone may beswitched off—so the message will arrive only when it is switched on,which may be days later. Since SMS does not involve a direct link withthe recipient, it is possible that the pet is being sent to a wrongnumber altogether. Such a problem cannot be determined when sending thetext message.

The problem of the wrong number is overcome at the receiver's side usingthe non-supported message referred to above.

The above problems may be summed up as follows: the user has no ideawhen or if the pet-bearing message will reach its destination. Thus,returning to the example of the decoration in FIG. 8, suppose a usersends a decoration to a friend. After the decoration is sent, it isdeleted from the user's phone. If the SMS does not arrive at therecipient's phone, the decoration is lost in both locations.

In other cases it may be desired to send a pet to play in a friend'sphone, and then have it come back home. Such a feature considerablyenriches the community aspect of the self-developing pet and thereforeit is preferable that the feature can be supported reliably. Part of thefeature is that when the pet is sent away from its source telephone ithas to disappear from the source phone.

A trivial implementation is to use two back to back SMS messages: thefirst is sent from the sender to the recipient, and the other is sentfrom the recipient back to the sender after a few minutes, returning thepet home. The above is a risky solution, since the recipient may neveractually receive the SMS, or the SMS may be corrupted on receipt. Insuch a case, the recipient may never send the response SMS, and the petwould be lost forever, meaning its status on the source telephone wouldremain “away”.

Another possible problem is that the pet-sending SMS may be receivedonly after a long time. This may occur if say the recipient's telephonewas switched off for two days. The result is a long overdue return SMS.

The above issues are illustrated in FIG. 10 which is a flow chartshowing the passage of the pet between the user's phone 1001 and therecipient's phone 1003 over time. The pet is sent to the recipient instage 1005 and disappears at that point from the sender's phone. The petis received at the recipient's phone if his phone is switched on. Evenif the message is received at the recipient it may be corrupt or therecipient may be busy with something else. Assuming however that themessage is safely received and the recipient is not busy, the pet isplayed with and returned home with a return SMS, stage 1007.

However if the return message is not received by the sender for whateverreason then the naive scheme as set out above leads to the pet becominglost. Reference is now made to FIG. 11, which is a simplified flowdiagram illustrating an auto-return mechanism which deals with the aboveissues. The auto return mechanism ensures that if the pet is notreturned to the originating telephone within a predetermined time frame,typically a few minutes, say ten minutes, then the pet reappears on theoriginating telephone automatically. Late return messages are ignored,along with their data. The return message is not in fact required, sincecomplete data about the pet has always been present on the originatingphone. The above works if the SMS never reached its destination—wrongnumber etc., or if it did reach the destination but was ignored—userbusy or phone switched off, etc. or if the message was corrupted orthere were delays in the messaging path or for any other reason.

Reference is now made to FIG. 12 which illustrates an embodiment inwhich time signatures are used to synchronize between the sender andrecipient. Assuming that the two telephones have synchronized clocks,then it is possible for the recipient to identify and deal with stalemessages. The sender simply prepares an SMS 1201, and then attaches atime-signature to the sending SMS 1202. This signature is attached bythe sender, and represents the time in which the SMS was sent. Within asingle time zone there is little risk of unsynchronized clocks, sincethe cellular network can provide a time. The SMS is received by therecipient, 1204 and the time signature is checked against the currenttime, 1205. If the signature is fresh then the pet is played with andreturned 1206. However, if the recipient obtains an SMS which has astale signature, say several hours old, 1207, it may be treated in adifferent manner. For example the application may display a message suchas “A friend came to visit you, but you were not available, so hereturned home”.

Reference is now made to FIG. 13, which is a simplified diagramillustrating a model for providing trait and emotion behavior in thecharacter. A living pet has a different character which is reflected inits behavior. In the virtual world, what distinguishes a self-developingpet from any other kind of doll is its ability to change over time in away that seems natural. Thus in the present embodiments a mathematicalbehavior model that reflects and simulates natural pet character ispresented.

In order to model a pet characteristic the present embodiments involvethe creation of a mathematical scheme 1301 in which each pet has a setof traits 1303 that are changed according to external actions and eventsthat are operated on the pet. For example, an external event can be timechange (the pet will get hungrier) or an external action can be a usercommand (the user will order the pet to sit, stand, beg, roll over,shake, turn etc.). Any combination of traits state creates a singleemotion. The pet will act according to this emotion by performingactions that are related to this emotion. For example, when the pet ishappy it will do happy animations.

The general solution 1301 comprises three elements:

a. Traits 1303—A set of parameters that reflect the state of the pet.Traits are changed according to external events and actions according toa unique change function.

b. Emotions 1305—A set of emotions that are determined by a combinationof trait states by the translation function.

c. Pet Actions 1307—A set of action that reflects each state.

Unique Character Creation

Traits:

The traits are a set of parameters that reflect the state of the pet.These parameters hold the physical state of the pet. The traits arechanged according to external actions with a different change functionthat is coupled with the pet characteristics. Each pet can have its ownTraits, creating a variation of possible characteristics.

Emotions:

The emotions work in a similar way to the traits in that they areparameters, but this time they reflect the emotional state of the pet.

External Event or Action

An external event is an input event that can be external or internal tothe application. The external event typically starts a chain reactionwhich will eventually change the trait state of the pet. For exampleeach hour a time event occurs. The time event leads to a change functionwhich changes one or more of the current traits of the pet. Thus the petmay become more tired or hungrier.

There are also external actions that are not totally imposed on the pet.In these events the pet has the ability to choose if he would like toaccept or reject the action. After this external event the pet maydecide, according to its current trait state and emotion, if it choosesto accept or reject the external action. If the pet chooses to acceptthe action its traits will change according to an “Accept changefunction”. If the pet chooses to reject the external event its traitsmay change according to a “Reject change function”. These functionsdefine the traits as they will be following the action. For exampleaccepting food may lead to reduction of the hunger trait.

Change Function:ƒ(ExternalEvent, TraitState)=New TraitState

The change functions are a translation function between two traitsstates. Each pet type has a unique change function for each action orevent. And so external actions and events change the pet traits in aslightly different way for each character, creating many possiblecharacters. The result of the same user action on two different petcharacters will thus create two different states, one for each of thepets. Thus, slightly different change function can create numerousdifferent pet characters. For example one pet will be happier aftereating while the other one will be sleepier.

Reference is now made to FIG. 14, which is a simplified diagramillustrating a change function which brings about changes in eightdifferent traits represented by bar graphs. The graph on the leftillustrates a trait status prior to the event that triggers the changefunction and the graph on the right illustrates the trait statusfollowing the event.

Reference is now made to FIG. 15 which illustrates the same changefunction being applied to two different characters, character 1 andcharacter 2, leading to different end states which are substantiallyunique to each.

FIGS. 16 and 17 are screen shots which respectively show a currentstatus of a pet, followed by an action, followed by a graph of thetraits being changed, followed by a new status. In FIGS. 16 and 17 thecurrent status—hungry—and the action—eat—are the same but the traitschange is different (because the characters are different) andconsequently so is the new status.

Reference is now made to FIGS. 18A-C, which each illustrate differentpossible ranges of traits. Each Figure is a bar graph that illustrates acombination of traits, and FIG. 18B specifically leads to the overallemotion “happy”, as will be described in greater detail below. FIGS.19A-C illustrate change functions for each of the ranges of FIGS. 18A-Cand show for example how the happy emotion of FIG. 18B can be changedinto a sad emotion by virtue of an external action.ƒ(TraitState)=Emotion

The pet emotions are determined by a state of the traits. Each characterhas its unique translation function ƒ(TraitState)=Emotion whichtranslates a set of traits states into one or more emotions. Because thetranslation function is unique to each pet characteristic the same setof traits state may create a different overall emotion. For example aDog pet with “Fullness” >80% may be set to have a “Tired” Emotion whilea Cat pet may be set to have a “Joyful” emotion. This variation oftranslation function allows the creation of different pet characters. Inthe state where two translation functions yield two different emotionsthe system can do one of the following:

choose between two possible states, each defined by accepting only oneof the emotions. For example this may be achieved using an emotionpriority table, or the system can choose to join the accepted emotioninto an Emotion set where the two emotions (or more) are active at thesame time. For example the pet could be “Hungry” and “Tired” at the sametime.

For example ƒ(TraitState) could be:ƒ(TraitState)=if{(Fullness <20%}=>Emotion=Hungryƒ(TraitState)=if{((Strength <40%)And(Fatigue >80%}=>Emotion=Tiredƒ(TraitState)=if{(Health <40%)And(Strength <25%)}=>Emotion=PainAction:

Each emotion has a set of actions that reflects this emotion. Theactions in the set correspond to animations. Each screen, scenario orcharacter in the application can attribute a different set of actions toeach emotion. Doing so creates a variety of ways that the pet canreflects its emotions. There are many types of actions that the pet canperform, and a non-limiting list of actions that can vary according tothe emotional state is as follows:

a. Visual Effects—Different animation set for each emotion.

b. Vocal—Different sound set for each emotion.

c. Textual—Different text hint or text bubbles that the pet showsaccording to its emotion.

d. Rejection—According to the emotion state of the pet (Traits andEmotion) the pet can choose to reject the action asked by the user.

e. Etc . . .

Reference is now made to FIG. 20, which is a simplified state diagramillustrating how an event or action may be varied according to thecurrent emotional state and may also lead to a change function leadingto a change in the current state. The future actions are therefore inaccordance with the future state.

General Flow

Data Structure:

Referring now to FIG. 21 and the system has what are known as groundtables. The ground tables of the system are as follows:

-   2101 Pets—This table holds all pets that are currently on the phone-   2102 Traits—a set of all possible traits that pets could have.-   2103 Emotions—a set of all emotions a pet could have.-   2104 Action—a set of all actions a pet could perform.

There are connection table between the tables:

1. Pet Traits 2105—This table holds an index that attaches all possibletraits for a specific pet.

2. Pets Emotions 2106—This table hold all the current emotion that thepet has at the current time. The emotions in this table are the emotionsthat answer to the translation function of the traits state.

3. Emotions Actions 2107—This table hold all possible actions that couldbe performed for each emotion.

Development Model

1. The embodiment described above may be improved by distinguishing twoparticular emotions as development emotions. The development emotionschange more slowly than the other emotions. The development modelprovides a pet that is easier for a user to comprehend and for whichgreater differentiation can be provided between different breeds. Theresult is a greater sense to the user of dealing with a live pet. Inaddition progress appears over time.

In the development model:

Traits offsets are set to be the same for all breeds and ages. Howeverthe different breeds and ages differ in that the traits have differentmaximum values that they can attain. Exemplary offsets are shown intable 2 below.

The maximum values of the various traits are set according to thebreeds' characteristics.

Traits to be considered include: Health, Fatigue, Fullness, Cleanliness,Stress, Obedience, and Intimacy.

The first five traits may change rapidly and without much effort.Intimacy and Obedience are the special development traits, which meansthat they are much more persistent and long term. The user has to earnthe pet's trust as it develops. The pet cannot die, but the system canpunish the user for not taking care of his pet by dropping the intimacylevel.

The pet can learn to perform tricks. The user has to train the petspecifically for each trick. Learning curves preferably differ amongbreeds and ages. The user may scold or praise the pet after each commandto hasten or otherwise affect the learning process.

Emotions typically used include Sick, Hungry, Tired, Angry, Calm,Joyful. Emotion is determined according to the traits, with theexception of the development traits.

The pet may accept or reject an action on the basis of the emotionalstate and traits.

If the pet does not agree to an action, it preferably tells the userexactly why. Thus a pet may not eat because it is sick or it hasrecently eaten, in which case it will preferably inform the user “Idon't feel so good”, or “I am full”. The pet may refuse to go for a walkwith the user because the intimacy attribute is especially low, in whichcase it will inform the user “I don't want to go with you”.

In a preferred embodiment, intimacy and Obedience change more rapidlyfor puppies. Scold & Praise actions preferably affect different dogsdifferently, and even affect the same dog differently, say depending onthe last action, or the time that has elapsed since the last action.

Reference is now made to Table 1 which shows a series of emotions in apredetermined order. Each emotion is associated with one or more traits.Each trait is represented by a variable which ranges between 0% and 100%of a predetermined maximum value. In addition some values may berepresented by absolute values. A threshold value is set above which orbelow which the emotion has effect. Thus if health is below 25% then theanimal is sick. As sick is the highest emotion in the priority list theanimal is sick regardless of the lower items in the emotion table. Ifnone of the emotions are beyond their threshold then the animal is calm,the lowest item in the table.

Emotions

According to the Following Priority (Sick is Highest): TABLE 1 Emotionper trait level and their order of priority. Sick Health <25% HungryFullness <25% Tired Fatigue >75% Angry Stress >75% Joyful Health >70%and Fullness >50% and Fatigue <50% and Stress <30% Calm None of theabove

Reference is now made to Table 2 which shows values for changing theemotions over time. It is noted that the intimacy and obedience emotionschange more slowly than the others.

Hourly Changes TABLE 2 Changes over time (hourly) to traits Full- Clean-Inti- Obe- Emotion Health Fatigue ness liness Stress macy dienceJoyful/Calm/ 0 +7 −7 −1 −3 0 0 Tired/Angry Hungry −4 +9 −5 −1 0 −1 −1Sick −1 +15 −2 −1 0 −3 0

Reference is now made to Table 3 which illustrates the conditions underwhich a pet will accept a particular action if it is offered.

Accept Conditions: TABLE 3 Acceptance of Actions Walk Emotion Calm orJoyful. Intimacy >=70 Last walk more than 10 minutes ago. Game EmotionCalm or Joyful. Intimacy >=70 Eat Emotion not Sick. Sleep Emotion notAngry. Fatigue >50% Cure Health <50% Clean Emotion not Angry.Cleanliness <50%. Intimacy >50 Trick Emotion Calm or Joyful.Intimacy >=70 Trick was learned. According to Obedience level, the petmay refuse to perform (randomly) and then scolding may help raise theobedience level.

Reference is now made to table 4 which illustrates the affect on varioustraits of accepting the actions in table 3. TABLE 4 Effects of acceptingan Action Health Fatigue Fullness Cleanliness Stress Obedience IntimacyWalk X +8 −5 −2 −4 X +2 Ding-Dong X +6 −4 −1 −1 X +2 Stanga X +10 −6 −3−2 X +2 Learn-English X +3 −1 X X X +2 Today saying X X X X −1 X X EatIf full, −10 +1 +30 −3 −2 X +1 Sleep +3 To 0 −10 X −10 X X Cure To Max+20 −5 X +30 X −1 Clean +3 +10 −4 To Max +15 X −1 Command X +1 −1 X −1 X+1 Win race +1 +15 −10 −2 −8 X +2

Table 5 is the corresponding table that illustrates the effect ofrefusing an action. TABLE 5 Effect of Refusing an Action Full- Clean-Obe- Inti- Health Fatigue ness liness Stress dience macy Walk X X X X +1X X Eat X X X X X X X Sleep X X X X +1 X X Cure X X X X +15 X −2 Clean XX X X +5 X −2 Command X X X X X X X Lost race X +15 −10 −2 +5 X X

The effect of praising or scolding is set such that an action within aminute of the previous praise or scold has no affect.

If praising or scolding is carried out about a minute after a trickcommand, then the affects are as in tables 6 and 7. As shown the affectmay differ according to the pet's reaction to the command: that iswhether it has performed the trick, or has refused out of spite. TABLE 6Effects of a Scold Action Fa- Full- Clean- Obe- Inti- Health tigue nessliness Stress dience macy Punish X +2 X X +10 X −1 Caution X +1 X X +6 X−1 Punish X +4 X X X +2 X (after spite) Caution X +2 X X X +1 X (afterspite)

TABLE 7 Effects of a Praise Action Health Fatigue Fullness CleanlinessStress Obedience Intimacy Pet X X X X −4 X +1 Praise X X X X −5 X +1 Pet(after X X X X −4 +1 +1 preformed trick Praise (after X X X X −5 +1 +2preformed trick) Pet (after spite) X X X X X −2 X Praise (after spite) XX X X X −2 XTraits Maximum Values

As mentioned above, the traits are set with maximum values that reflectthe differences between breeds.

For example take the following breeds which have the following traits:

Cocker spaniel: They are natural retrievers and built to run intoundergrowth. Tolerant of children and other pets.

Papillon: Outgoing and friendly. Likes snuggling and playing. Can bevery difficult to house train. The Papillon needs regular brushing.

Beagle: They can be stubborn and difficult to train. Need constantactivity and may get bored easily. They are gentle animals who are greatwith children and other dogs. Brush as needed and only bathe whenabsolutely necessary.

Jindo: The Jindo is a lean yet muscular dog and carries itself proudly.The breed keeps itself clean and is extremely easy to house train.

The above traits can be represented by sets of maximum values as shownin Table 8. TABLE 8 Maximum values of various traits for differentbreeds. Fa- Full- Clean- Obe- Inti- Health tigue ness liness Stressdience macy Cocker Adult 100 90 120 100 110 200 200 Papillon Adult 80100 80 120 100 200 200 Beagle Adult 80 110 100 100 80 200 200 JindoAdult 120 130 110 80 110 200 200

Now younger and adult dogs can be defined as follows:

For a puppy: take 50% of the adult maximum value (except Obedience andIntimacy, which remain at maximum 200).

For mid-grown: take 80% of the adult maximum value (except Obedience andIntimacy, which remain at maximum 200).

Table 9 shows suggested initial values for a new puppy according to thebreeds exemplified above TABLE 9 Initial trait values per breed for anew puppy Full- Clean- Obe- Health Fatigue ness liness Stress dienceIntimacy Cocker 100% 0 50% 100% 0 100 100 Papillon 100% 0 50% 100% 0 80120 Beagle 100% 0 50% 100% 0 70 100 Jindo 100% 0 50% 100% 0 120 80

The puppy may grow and be brought to peak physical condition (Health100%, Fatigue 0, Fullness 100%, Cleanliness 100%, Stress 0). Obedienceand Intimacy need not change.

Learning of tricks is also breed dependent. Table 10 shows suggestedvalues of a learning table for different breeds. The table indicates howmany times it is necessary to train the dog with a trick before it knowsthe trick: TABLE 10 Number of times needed to learn a trick per breedSit Roll Turn Bark Paw Cocker 5 15 6 10 7 Papillon 9 22 9 14 12 Beagle 720 7 12 10 Jindo 2 7 4 6 5

Reference is now made to table 11, which illustrates a number of snacksand indicates accept conditions for the pet to take the snack. The tablealso illustrates the effect on existing traits of the pet accepting thesnack.

It is noted that while the presently preferred embodiments refer tosending text-encoded binary regarding pet information, the principle ofusing an SMS message to communicate parameter data for a commonly helduser client may be applicable to other applications and other types ofinformation and is within the scope of the present invention.Furthermore, the principle of using text-encoded binary data for directcontact between mobile devices is likewise within the scope of thepresent invention and the concept of using text-encoded binary data forcommunication between user clients over the air is also within the scopeof the present invention. The principle of using text messaging totransfer binary data between mobile devices is likewise encompassed bythe present invention.

The above principles may be extended to other types of information fortransfer between mobile and other limited resource devices. It isexpected that during the life of this patent many relevant devices andsystems will be developed and the scope of the terms herein,particularly of the terms mobile device, cellular communication, textmessage, etc. is intended to include all such new technologies a priori.

Additional objects, advantages, and novel features of the presentinvention will become apparent to one ordinarily skilled in the art uponexamination of the following examples, which are not intended to belimiting. Additionally, each of the various embodiments and aspects ofthe present invention as delineated hereinabove and as claimed in theclaims section below finds experimental support in the followingexamples.

Example of Use: A Race

A significant feature of the self-developing pet in a mobile device isthat experiences with the self-developing pet can be shared and acommunity of users can be created. One way to share a self-developingpet and the associated experiences is to have joint activities in whichthe pets work together or compete with each other. This may or may notbe achieved by sending one pet to a friend's phone.

One activity that is possible is the race. Two self-developing pets arepresent on the same phone and compete with each other in a race. Theattributes, traits and emotions of the self-developing pets determinewho wins so that the user who has invested more time and care in his petwins.

Reference is now made to FIG. 22 which is a simplified diagram showing asequence of possible screen shots involved in initiating a race.

Any user can initiate a Race by sending an SMS to another user who has avirtual pet installed on his phone—screen shot 2201. The user whoreceives the SMS can accept or decline the Race proposal, screen shot2202.

If the recipient accepts the Race proposal, then his telephone enters astate in which he sees the two pets (his own, and the sender's pet)stretching and preparing for a Race. A countdown from 3 to 1begins—screen shot 2203. Referring now to FIG. 23, when the countdownfinishes, a flag is presented to indicate the start of the Race—screenshot 2301.

The two pets begin the race in a stadium, and preferably run in separaterunning lanes. The pets run through the curves of the running lanes,through three different backgrounds 2302, 2303 and 2305. Once they reacha certain point in the 3^(rd) background, one of the pets starts tospeed to the finish line in 2401.

The winner of the Race is decided upon the pet traits. The exemplaryformulae to calculate a score for each pet is as follows:2*(pet's strength value+pet health value)—1.5*(pet's fatigue value)OrPet's obedience value+pet health value−1.5*(pet fatigue value).

Other similar relations may also be utilized with similar or alternativetraits and emotions.

The pet with the highest score wins the Race. If the scores are equal,the user that received the Race proposal, wins the Race.

The sequence at the end of the race depends on which pet wins. If thevisitor pet wins then the sequence of screen shots 2401, 2403, 2405 isshown. If the home pet wins then the sequence 2410, 2412, 2414 is shown.

In a preferred embodiment the race may be shown simultaneously on thesender's and receiver's phone. Since both phones calculate the winner inthe same way the phones do not actually need to synchronize with eachother for this purpose. The end of the race is thus different on eachphone since the announcement of the result has to show what the home petdid.

The race serves as an incentive for the users to develop their pet, forexample by increasing their pet's strength by feeding him, or byincreasing their pet's health by curing him, and giving him medicines,it's also an incentive for the users to let the pet sleep from time totime, so his fatigue will be minimum. Furthermore it serves as a focalpoint for users to compare their efforts since the best treated petwins. After the Race is finished the winner's pet gets a gold medal andthe loser gets a silver medal.

If the home pet wins then the visitor (the loser) gets an SMS withSilver medal, and if the home pet loses he gets a silver medal and thevisitor (the winner) gets an SMS with Gold medal.

The medals are preferably added to the pet's decorations inventory, andcan be worn at any time. After the Race is finished, the originator whosent his pet to the recipient receives his pet back.

After the Race is finished, both pets' traits are modified. An exemplarymodification is the following:

For both competitors:

Strength: −5 points, Health: −5 points, Fatigue: +3 points, Fullness: −5points,

Cleanliness: −5 points, Intelligence: +2 points, Intimacy: no change.

For the winner:

Satisfaction: +20 points, Stress: −5 points.

For the loser:

Satisfaction: −5 points, Stress: +20 points. Reference is now made toFIG. 25, which is a simplified flow chart that illustrates the generalflow for the race. As explained above, an originating user sends the petto the recipient for the race. The recipient receives and accepts theinvitation to race. If the recipient does not accept the race then thepet is returned to the originator. Otherwise the race begins. The pets'scores are calculated and one of the pets wins the race. The appropriatepet owner is informed of the victory and the other pet owner of thedefeat and the originator's pet is returned to its source.

In somewhat more abstract terms the race may be replaced by any othertask, preferably a competitive task, meaning any task wherein acharacter finishing first or winning or doing better can be identified.Such a task provides a method of electronic competition which includesdeveloping attributes through one's own electronic character, and thensetting the competitive task for the electronic character to performwith, or more accurately against, one or more other electroniccharacters within the virtual environment of the mobile telephone.

Within the electronic environment a winner of the competitive task isthen selected from amongst the characters via assessment of thedevelopment of the attributes. Thus the user who puts more effort intohis pet wins the race. The race gives a chance for users to share theirpets and benefit from the level of development that they have put intotheir pets.

It is appreciated that certain features of the invention, which are, forclarity, described in the context of separate embodiments, may also beprovided in combination in a single embodiment. Conversely, variousfeatures of the invention, which are, for brevity, described in thecontext of a single embodiment, may also be provided separately or inany suitable subcombination.

Although the invention has been described in conjunction with specificembodiments thereof, it is evident that many alternatives, modificationsand variations will be apparent to those skilled in the art.Accordingly, it is intended to embrace all such alternatives,modifications and variations that fall within the spirit and broad scopeof the appended claims. All publications, patents, and patentapplications mentioned in this specification are herein incorporated intheir entirety by reference into the specification, to the same extentas if each individual publication, patent or patent application wasspecifically and individually indicated to be incorporated herein byreference. In addition, citation or identification of any reference inthis application shall not be construed as an admission that suchreference is available as prior art to the present invention.

1. An electronic device carrying computing functionality, displayfunctionality, and interconnectivity functionality for transmitting dataover a network, the device comprising: dynamic data, and static data,said dynamic and static data being combinable to represent a characteron said device, and a character sharing unit for using saidinterconnectivity functionality to allow said character to be sharedwith other devices over said network.
 2. The device of claim 1, whereinsaid character sharing unit is configured to send said dynamic data toother devices to carry out said sharing, said static data being assumedto be present on said other devices.
 3. The device of claim 2, whereinsaid dynamic data for sending includes a pointer for identification ofan avatar from a group of avatars.
 4. The device of claim 1, whereinsaid character sharing unit is configured to use text messaging to carryout said sharing.
 5. The device of claim 4, wherein avatars are locatedon said other devices and said text messaging carries said dynamic dataincluding a pointer to an avatar associated with a respective pet. 6.The device of claim 5, further comprising a presence control unit forcontrolling said character sharing unit to ensure that said characterhas a unified presence on said network.
 7. The device of claim 6,wherein said presence control unit is configured to prevent presence ofsaid character at said device when said character has been sent toanother device.
 8. The device of claim 7, wherein said presence controlunit is configured to reinstate presence of said character at saiddevice if said character does not return from said another device aftera predetermined time.
 9. The device of claim 8, wherein said presencecontrol unit is configured to reinstate presence of said character atsaid device when said character returns from said other device byacceptance of said character specific data as modified by said otherdevice.
 10. The device of claim 6, wherein said presence control unit isconfigured to allow said character to appear on an originating deviceand on said other device but to allow modifying of said characterspecific data only on said other device.
 11. The device of claim 6,wherein said presence control unit is configured to allow said characterto appear on an originating device and on said other device but to allowmodifying of said character specific data only on said originatingdevice.
 12. The device of claim 4, wherein said character sharing unitis configured to place a signature on a text message carrying saidcharacter specific data to render said text message recognizable ascomprising character specific data for operating said character on saidother device.
 13. The device of claim 12, wherein said character sharingunit is configured to place binary data in said text message.
 14. Thedevice of claim 12, wherein said character sharing unit is configured toscan incoming text messages for signatures indicative of character datacontent.
 15. The device of claim 14, wherein said character sharing unitis configured to carry out said scanning prior to a respective textmessage being sent to client applications.
 16. The device of claim 1,wherein said character specific information comprises emotion parameterdata for an emotion engine, said emotion engine being configured toprovide emotion-based behavior for said character.
 17. The device ofclaim 16, wherein said emotion engine is configured to evolve saidemotion parameter data slowly over time, thereby to provide developmentof said emotion-based behavior for said character.
 18. A systemcomprising a plurality of mobile communication devices, each devicehaving computing, display and communication functionality, andcomprising: an engine for operating characters, the characters havingpersonal behavior and an avatar, and an exchange unit for allowing saidcharacters to be exchanged with other mobile devices so as to operatewith the same personal behavior and appearance thereon, thereby toprovide a community environment for operating said characters.
 19. Thesystem of claim 18, wherein each mobile device has a similar set ofavatars and a behavior engine to provide behavior according to behaviorparameters, such that said being exchanged is accomplishable for a givencharacter by indicating which avatar is to be used and providingrespective behavior parameters.
 20. The system of claim 19, wherein saidexchange unit is configured to indicate which avatar is to be used andto provide said behavior parameters by inclusion in a text message. 21.The system of claim 20, wherein said exchange unit is configured to marksaid text message with a signature.
 22. A method of exchangingcharacters over a mobile telephony network between a plurality of mobiledevices, comprising: providing at each of said plurality of mobiledevices a behavior engine for providing character-specific behavioraccording to character-specific behavior parameters; providing at eachof said plurality of mobile devices static data for display ofrespective characters, and exchanging a given character between mobiledevices by sending respective character-specific behavior parameters andidentifying relevant static data.
 23. The method of claim 22, furthercomprising selecting some of said behavior parameters as developmenttraits that develop more slowly than other parameters to provide stabledevelopment of respective characters.
 24. The method of claim 22,further comprising selecting maximum values for respective parameters,thereby to define a character type, and whereby a new character type canbe added by defining a new set of maximum values.
 25. A system forinteraction between limited resource devices, each device comprising alocal copy of a common user client, the devices being configured toexchange at least one text message to communicate parameter data forsaid commonly held user client.
 26. The system of claim 25, wherein saidlimited resource devices are cellular communication devices.
 27. Thesystem of claim 25, wherein said text message comprises text encodedbinary data.
 28. A system for interaction between limited resourcedevices, wherein the limited resource devices are configured with aclient for exchange of text-encoded binary data, for direct contactbetween said limited resource devices.
 29. The system of claim 28,wherein the limited resource device is a cellular telephony device. 30.The system of claim 28, wherein said client for exchange of text-encodedbinary data is configured to form said text encoded binary data into atext message with an identifying header, and to recognize incomingmessages having such a header.
 31. A method of electronic competitioncomprising: developing attributes through a first electronic character,setting a competitive task for said electronic character to perform withat least one other electronic character having corresponding attributeswithin a first virtual environment; and within said first virtualenvironment selecting a winner of said competitive task from said firstand said at least one other characters via assessment of a developmentlevel of said attributes.
 32. The method of claim 31, wherein said firstvirtual environment is within a first cellular communication device andwherein said at least one other electronic character is transmitted tosaid cellular telephony device.
 33. The method of claim 31, wherein saidattributes comprise at least one of the group consisting of a trait, andan emotion.
 34. The method of claim 31, wherein said attribute isaffected by being selected or not selected as a winner.
 35. The methodof claim 32, wherein said transmitting comprises sending by textmessaging.
 36. The method of claim 31, wherein said text messagingcomprises making use of the short messaging service (SMS).
 37. A methodof communicating binary information between client applications onmobile devices comprising: formulating said binary information into atleast one text message at a client application on a first mobile device,said text message being formulated for reading by a corresponding clientapplication on a recipient mobile device; adding to said text message ahuman readable header to appear on recipient mobile devices not equippedwith a corresponding client application; and sending said text messageto a recipient.